Granular restore of data objects from a directory service

ABSTRACT

A system and method for performing a granular restore of data objects from a directory service is disclosed. In one embodiment, at the time a backup of the directory services database is performed, a metadata file with index values for some data objects is created. The metadata file may include an index of the name and an object identifier for each included data object. During granular restore of one or more data objects selected for restoration, the corresponding object identifier is retrieved from the metadata file using the name of the data object. The object identifier is then used to restore the data object in the directory service.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of information processing systemsand, more particularly, to backup and restore of data objects from anobject database.

2. Description of the Related Art

Modern computer networks include so-called “directory services,” whichare software applications (or sets of applications) for storing andorganizing information about users, services and resources. A directoryservice also allows network administrators to manage users' access toresources. Common directory services include NIS (Sun Microsystems,Inc.), eDirectory (Novell, Inc.), Fedora Directory Server (Red Hat,Inc.), Active Directory and NTDS (Microsoft Corp.), Open Directory(Apple Computer, Inc.), ApacheDS (Apache Software Foundation), OID(Oracle Corp.), and also the open-source software OpenLDAP. The X.500series developed by ITU-T is a series of computer networking standardscovering electronic directory services.

A given directory service is associated with a “directory repository,”which is the database that stores the information that is managed by thedirectory service. For example, a directory repository may include oneor more “namespaces” that include a hierarchy of data (e.g., dataobjects). The directory service thus acts as an interface that canauthenticate access to the system resources that manage data in thedirectory repository. For example, a directory service allows thedirectory repository to be searched on the many different attributes orobject identifiers that can be associated with objects within therepository.

A backup of a directory repository associated with a directory serviceis generally “monolithic”—that is, the entire repository is replicated.The corresponding restore operation for a directory repository is oftenmonolithic as well. Monolithic restore operations are often complex,inefficient, and time-consuming.

SUMMARY

Various embodiments of a method and system for backing up and restoringdata objects of a database associated with a directory service aredisclosed. In one embodiment, a method for backing up the objectdatabase by a computer system comprises copying a plurality of dataobjects from a database to a backup medium, wherein said database isassociated with a directory service.

For at least a first of said plurality of copied data objects, thedatabase is queried to determine a first private object identifier (POI)associated with the first data object, wherein the POI is usable torestore the first data object via a first interface of the directoryservice, and wherein said computer system is not configured to generate,from the backup medium, the first POI. Additionally, the first POI isstored as metadata associated with the first data object.

In some embodiments, the first POI may be generated using a proprietaryprotocol associated with the directory service. The metadata may bestored in a metadata file, where the metadata file includes an indexvalue and an associated POI for each of one or more of the plurality ofcopied data objects. The metadata file may also be stored on the backupmedium.

In still further embodiments, a request to restore the first data objectto the directory service is initiated. The first data object is receivedfrom the backup medium. The previously stored metadata associated withthe first data object, including the first POI, are received. Then, thefirst POI and the received first data object are used to restore thefirst data object via the first interface of the directory service. Atleast a portion of the POI may be encrypted. The first interface may bea cached API and the first POI may be required to access the directoryservice via the first interface.

In some embodiments, the computer system is configured to perform thebackup via a second interface to the directory service. The first andsecond interfaces may be different interfaces of the directory serviceusing different authentication protocols.

In yet another embodiment, a request to restore a first data object froma backup medium to a database associated with a directory service isinitiated. The first data object is received from the backup medium. Afirst object identifier is received from a location external to thedatabase, wherein the computer system is not configured to generate thefirst object identifier from the backup medium. The received first dataobject and the received first object identifier are used to restore thefirst data object to the database. The first interface may use anauthentication protocol that includes, for the first data object, thefirst data object and the first object identifier.

The generation of said first object identifier may use a proprietaryprotocol associated with the directory service, wherein at least aportion of said first object identifier is encrypted. The directoryservice may be accessible using a lightweight directory access protocol(LDAP). The first interface of the directory service may be accessiblevia a cached API.

Another embodiment is represented by a computer readable mediumincluding program instructions executable to backup and restore dataobjects according to the methods described herein. A computer systemembodiment includes a processor and a memory storing programinstructions executable by the processor to backup and restore dataobjects according to the methods described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of one embodiment of an archival system.

FIG. 2 illustrates one embodiment of a method for accessing archiveddata objects.

FIG. 3 illustrates one embodiment of metadata used for restoring dataobjects.

FIG. 4 illustrates one embodiment of a method for archiving dataobjects.

FIG. 5 is a block diagram of one embodiment of a computer system.

FIG. 6 is a block diagram of one embodiment of a backup system.

While the invention is susceptible to various modifications andalternative forms, specific embodiments are shown by way of example inthe drawings and are herein described in detail. It should beunderstood, however, that drawings and detailed description thereto arenot intended to limit the invention to the particular form disclosed,but on the contrary, the invention is to cover all modifications,equivalents and alternatives falling within the spirit and scope of thepresent invention as defined by the appended claims.

DETAILED DESCRIPTION

Referring to FIG. 1, a block diagram is shown of one embodiment of anarchival system 100 for a database or directory repository associatedwith a directory service. As illustrated, database 102 is associatedwith a directory service 101, which is configured to manage and maintaina plurality of data objects for a plurality of system users or clientsystems. Some standards for directory services include X.500 and thelightweight directory access protocol (LDAP). An application program104, which in this embodiment includes a backup module 110 and a restoremodule 130, interfaces to database 102 via interfaces 107 and 117.Backup module 110 interfaces to metadata file 120 and backup medium 122via interfaces 111 and 109, respectively. Similarly, restore module 130interfaces to metadata file 120 and backup medium 122 via interfaces 113and 119, respectively.

In FIG. 1, database 102 is associated with directory service 101.Directory service 101 acts an interface to programs or services wishingto access database 102. For example, the backup and restore modules (110and 130, respectively) of application program 104 access database 102via interfaces 107 and 117. In other embodiments, application program104 and other programs may interface directly with database 102.Directory service 101 and database 102 may include user interfaces,program code and data interfaces for operating directory service 101.Database 102 may further include tables, indexes, relationships,queries, stored procedures, file systems, security layers, networkinginterfaces, etc., as needed to access the constituent plurality of dataobjects (also referred to as records or entries). One embodiment of adatabase 102 is a relational database, in which the records are arrangedin tables according to a row and column arrangement. In anotherembodiment, database 102 is an object database, in which the dataobjects are organized according to one or more hierarchical namespaces.In various embodiments, database 102 includes a core data store thatuses the Indexed Sequential Access Method (ISAM). Directory service 101is an interface for creating and modifying database 102 for storing andaccessing information according to the particular implementation ofdatabase 102 (e.g., relational database, object database). In someembodiments, database 102 executes on a dedicated computing system thatis configured for access by other server and client computers via acommunications network.

As mentioned previously, database 102 and directory service 101 may beconfigured differently in various embodiments. For example, database 102may be wholly embedded within directory service 101. In another example,database 102 may be accessed independently of directory service 101. Invarious embodiments, at least some of the accesses to database 102 areindependent of directory service 101, while other accesses to database102 are via directory service 101.

Directory service 101 may provide an interface to data objects containedin one or more “namespaces” or “directory trees.” A directory servicemay thus include a definition of a “namespace” for a computer network. Anamespace is the set of rules that define how network resources arenamed and identified. Each entry stored in the database of the directoryservice (i.e., each data object) can be specified using attributes thatestablish a unique and unambiguous name. The data objects may beorganized in a hierarchical namespace with parent and child classes ofobjects. The information defining a particular hierarchical namespace isalso referred to as a “directory information tree.”

The objects in database 102 (e.g., objects in a directory informationtree) may be accessed using an “object identifier,” which may include aroot and successive nodes within the namespace. In this notation, aseries of numbers representing nodes identify each node in a directoryinformation tree. One example of an object identifier is the AbstractSyntax Notation One (ASN.1) standard defined by ITU-T (Geneva,Switzerland). In directory services that use LDAP, each class of dataobjects and each type of attribute is also assigned a unique objectidentifier. Other attributes in an object name can include security andaccess parameters.

The object identifier associated with a data object may occur in a widevariety of formats. As mentioned above, ASN.1 is a standard notation forobject identifiers used with LDAP and other types of directory services.Even within the ASN.1 standard, there are several kinds of encodingrules for compressing or encrypting object identifiers. However, someimplementations of directory services rely upon object identifiers thatcannot easily be generated outside of the corresponding directoryservice/database. Such object identifiers are “private” relative to agiven computer system if the computer system is not configured togenerate the object identifier outside of the context of the directoryservice and corresponding database. For example, an object identifierthat is generated by a proprietary algorithm within a database (e.g.,the ASN-based-notation identifier with Microsoft's Active Directory) isprivate relative to a computer system that is not configured to run theproprietary algorithm. A private object identifier may be referred to asa “POI.”

A POI, similar to a standard object identifier, may be in the form ofbinary data, such as a number or a string, and may be limited to aspecific size or data type (i.e., 32-bit integer). The POI may be justan index value that refers to an entry in a list of additionalobject-identifying data. The POI may also include additionalinformation, including information relating to one or more of thefollowing: hardware platform, network domain, user identification,access control list, system interface, encryption certificate, etc. APOI for a data object may include an encrypted or compressedrepresentation of at least a portion of a non-private object identifierfor the data object.

In one embodiment, an object identifier can be queried from animplementation of a directory service, but cannot generally be obtainedfrom a copy of the data object. For example, an object identifier may bethe result of a proprietary algorithm that operates on anASN.1-compliant object identifier. The directory service implementingthe proprietary algorithm to generate the object identifier may requirethe identifier for certain types of access to the database. In oneembodiment, a directory service may require that an object identifiergenerated using proprietary means be provided as part of anauthentication protocol for replacing or creating data objects in thedatabase. In some embodiments, the POI may be used with an interfacelayer associated with one or more types of directory services. Forexample, Microsoft's Active Directory Services Interface (ADSI) requiresan object identifier in a proprietary format for accessing data objectsin Active Directory.

As stated above, application program 104 may access database 102 viainterfaces 107 and 117, respectively. In particular, backup module 110may access database 102 via interface 107, while restore module 130 mayaccess database 102 via interface 117. Interfaces 107, 117 may include alocal or remote network interface, and may also include network and/orsoftware driver layers for communicating with database 102. In oneembodiment, interfaces 107, 117 provide an SQL (Structured QueryLanguage) interface to database 102. In another embodiment, interfaces107, 117 access database 102 using a lightweight directory accessprotocol (LDAP) via directory service 101. In one particular embodiment,directory service 101 is a Microsoft Active Directory and interfaces107, 117 are Joint Engine Technology (JET Blue) or Extensible StorageEngine (ESE) interfaces (also from Microsoft Corporation) for accessingdatabase 102. Interfaces 107, 117 may also provide for access viastandardized application programming interfaces, known as APIs.

An API for accessing interfaces 107, 117 may include a library ofsoftware functions which can be called by external programs foraccessing database 102 via directory service 101. In one embodiment, theAPI for interfaces 107, 117 that encapsulates additional protocol layersalso includes a caching mechanism for processing multiple transactions.Some APIs for interfaces 107, 117 may provide access to a variety ofspecific implementations of directory services 101 and its associateddatabase 102, such that program code developed using the API functionscan be used with different kinds of directory services 101. One exampleof a cached API for accessing directory services 101 is the ActiveDirectory Services Interface (ADSI) by Microsoft, Corp. In someembodiments, ADSI is a standardized API associated with interface 107,117 that can accept a POI as a parameter for a function that accesses adata object. It is noted that an API may encapsulate addition interfacelayers. For example, ADSI encapsulates interface layers LDAP andJET/ESE.

In some configurations, where an API is used via interfaces 107, 117,the API may generate an object identifier for accessing data objects.The means for generating this object identifier may not be availableoutside of the API, resulting in an object identifier that is “private.”Furthermore, in some embodiments, the API may require the objectidentifier for write access to data object via interface 117 (i.e.,write, overwrite, delete, create, restore, etc.). In someconfigurations, the object identifier may represent an element of thesecurity model that protects the data in directory service 101. In someembodiments, an ASN.1 encoded object identifier is required by an API atinterface 117.

Application program 104 is configured to backup and restore the contentsof database 102. Although application program 104 is shown as includingboth backup module 110 and restore module 130, in another embodiments,the backup and restore function are in separate programs. Backupapplication 110 and restore application 130, singly or in combination,may also be configured to provide other known archiving functionality,as desired, such as various features provided by the Enterprise Vault™or Backup Exec™ products from Veritas Corporation.

Application program 104 is operable (via backup module 110) to archivecopies of data objects from directory service 102 to backup medium 122.Backup medium 122 may be any suitable type of memory medium, including atape drive, a disk drive, a storage array, an entire storage sub-system,etc. Backup medium 122 may also be located at a remote site, in whichcase interfaces 109 and 119 include a network interface. For example,backup medium 122 may be a storage area network (SAN) in someembodiments, or a logical volume created on a SAN. Application program104 (via restore module 130) is also operable to restore data objectsfrom backup medium 122 to database 102.

Backup medium 122 may be accessed by restore module 130 of applicationprogram 104 via interfaces 109 and 119. In some embodiments, interfaces109 and 119 may not be configured with the same functionality,complexity or security that interfaces 107, 117 provide in someembodiments, as the data stored on backup medium 122 may not be anoperational directory service, but an archived copy of the informationin database 102. In other embodiments, interfaces 109 and 119 aresimilar to the interfaces 107 and 117 described above. For example,where directory service 101 is Active Directory, interfaces 109 and/or119 can be JET-ESE interfaces. Interfaces 109 and 119 can also include alocal or wide-area network, in the case of a backup medium 122 that isremote from directory service 101 and database 102.

During the backup process, backup module 110 of application program 104is also configured to determine “metadata”—that is, data associated withdata objects that have been copied to backup medium 122. In oneembodiment, the metadata for a particular data object is read fromdatabase 102 at approximately the same time the data object is copied tobackup medium 122. In one embodiment, the metadata is then copied tometadata file 120, which may be the same located on backup medium 122 orany other suitable storage medium. Metadata file 120 and backup medium122 need not be located on the same storage medium, or in the samestorage network. Although metadata file 120 is shown as a single file,it may be stored as a plurality of files, as data objects, within adatabase, or any other suitable means.

The metadata for a particular data object includes, but is not limitedto, an object identifier (e.g., a POI) that is usable to access database102 via interface 117. In some embodiments, the object identifier/POIfor a particular data object may be usable to allow application program104 to restore individual data objects (and not simply the entiredatabase as part of a monolithic restore operation). In this manner, a“granular” restore feature is achieved. The metadata stored in metadatafile 120 may also include additional information—for example, an indexof POIs along with the corresponding name for each of the data objectsstored on the backup medium.

For example, using the ADSI interface to access an Active Directory, anobject identifier is returned upon querying data objects for backup.This same object identifier is required for restoring the data objectsvia ADSI. If the object identifier of a data object to be restored isnot available, then the data object cannot be restored in a granularmanner using ADSI. Since the POI is associated with communicationbetween directory service 101 and database 102, it is not stored indatabase 102. Therefore, there is no provision for storing POIs on thebackup medium during backup of database 102.

When a POI is needed to access an interface of database 102, themetadata stored in metadata file 120 can be used by restore module 130of application program 104 to restore one or more data objects from thebackup medium 122 to database 102. Restore module 130, upon beingrequested (via a graphical user interface or otherwise) to restore oneor more data objects, accesses metadata file 120 to determine the POIsfor the data objects desired to be restored. Restore module 130 thenuses these POIs to access database 102 via interface 117 in order torestore data from backup medium 122.

The restoration of a selected data object may be preceded by readingcertain index values from backup medium 122 and using these index valuesto index information in metadata file 120. For example, restoreapplication 130 may read the name (or other metadata) of a selected dataobject from backup medium 122 and use the name to retrieve a POI forthat data object from metadata file 120. In this manner, POIs for one ormore data objects may be supplied by restore application 130 tointerface 117, along with other information, for reconstructing therespective data objects in directory service 101. In variousembodiments, other kinds of metadata may be stored as index values inmetadata file 120. Also illustrated in FIG. 1 is backup application 110,which can be configured to perform a backup of the contents of thedatabase 102 associated with directory service 101. As will be discussedin detail below, backup application 110 can be configured to generateand store metadata 120 associated with data objects along with thebackup of database 102 stored on backup medium 122. It is noted thatbackup medium 122 may represent an identical instance of the database102 at the time the backup was performed. The metadata 120 may then beused to access or restore the contents of backup medium 122 and torestore individual data objects in directory service 102.

Backup application 110 is operable to archive to a backup medium such asremovable storage (or any other type of archive storage). Alternatively,selected data objects may be transferred from directory service 102 to aremote archive storage through a network interface. Restore application130 is operable to restore data objects or other data acquired fromprevious archive operations to directory service 102.

It is noted that in the embodiment illustrated in FIG. 1, backupapplication 110 may communicate with directory service 102 via interface107 for selecting and retrieving content for archiving. In variousembodiments, interface 107 between backup application 110 and directoryservice 102 may include a network connection along with the necessarynetwork and software drivers, as previously mentioned. The backupapplication generates a backup copy of the database 102 on backup medium122, which may be stored on a storage medium separate from directoryservices 102 or in other appropriate locations.

Turning now to FIG. 2, one embodiment of a method 200 for restoring dataobjects is illustrated. The method 200 may be executed in one embodimentby restore application 130. In step 202, the backup repository 122 isopened for reading. In one embodiment of step 202, an open command issent via interface 119 with parameters specifying the backup repository122. In another embodiment, a database engine, for example JET-ESE(Microsoft Corp.), is used to open a connection to repository 122 instep 202. It is noted that steps shown in method 200 may be optional orarranged in a different manner in various embodiments.

In step 204, the metadata file is opened for reading. In one embodimentof step 204, a file open command is sent to the file system withparameters specifying the metadata file 120. In another embodiment ofstep 204, wherein the metadata file has been embedded within backuprepository 122, the metadata file is located and extracted. In step 204the contents of the metadata file 120 may be read, parsed, and madeavailable to restore application 130. In one embodiment, restoreapplication 130 reads data from metadata file 120, including the nameand POI for each data object being restored, as desired.

In step 206, an attribute of the data object to restore is selected. Theattribute is used to identify the data object, for example, a name orobject identifier for the data object. The selection may be performedwithin restore application 130. Data objects for restoration may beselected from a list of available data objects, for example, with a userinterface. In some embodiments, the available data objects are queried(based on an attribute value) and a selection is made from the queryresults. In some embodiments, the selection of data objects in step 206may be performed by accessing the metadata file 120, and reading thenames of data objects available for restoration. It is noted that inmethod 200, steps 206-212 are described for a single data object. Oneskilled in the art would appreciate that these method steps could berepeated in other embodiments for any number of data objects. In someembodiments, steps 206-212 could be individually performed for aplurality of data objects, as desired. In one embodiment of step 206,the name of the data object is used to identify which data objects havebeen selected for restoration.

In step 208, the name of the one or more data objects selected in step206 are used to look up the POI for each data object in the metadatafile 120. (As described in detail below with respect to FIG. 4, therespective POIs for the selected data objects have been previouslystored during backup in metadata file 120.)

In step 210, the one or more data objects selected in step 206 areretrieved from the backup copy of the directory repository 122. Theretrieval of data objects from backup repository 122 can be performed byrestore application via interface 119. As will to be appreciated by askilled artisan, step 210 may alternatively be performed prior to step208 in some embodiments. If for some reason, some data objects, cannotbe retrieved from backup repository 122, the method may skip furtherprocessing for those data objects and may optionally return an errormessage with indication of the issue at hand, while restoration of otherdata objects continues. In some embodiments, the entire restoration ishalted if any one of the selected data objects cannot be retrieved instep 210.

After the selected one or more data objects have been retrieved in step210, the individual data objects are restored in step 212. A respectivePOI may be used to identify and restore data objects via interface 117.For example, if interface 117 represents an ADSI interface, a POI in theASM.1 format can be provided for each data object being restored. Otherformats and interfaces may be implemented in various embodiments. Insome embodiments, depending on the size or number of the one or moreselected data objects, step 212 may be performed sequentially orcollectively with respect to the data objects. As noted previously,interface 117 may include a caching function for enabling restoreapplication 130 to rapidly execute for a plurality of data objects. Thusthe method step 212 represents a granular restore for selected dataobjects that does not require the restoration of the entire directoryservice 102, and can be performed while directory service 102 remainsinstalled and operational.

Referring now to FIG. 3, the contents of an illustrative set of metadatastored in metadata file 120 are shown. In the embodiment shown in FIG.3, the metadata file 120 is a lookup table, wherein the names 310 andPOIs 312 of a number of data objects have been indexed to each other(e.g., by backup module 110 during a previous backup of database 102).The actual format of the metadata file 120 may of course vary. Such ametadata file may be used to facilitate the restoration of data objectsto database 102 by providing, in response to an attribute such as thename of a data object, a POI that may be needed to restore a data objectvia interface 117 to database 102.

Referring now to FIG. 4, one embodiment of a method 400 for querying adirectory service 102 to generate a metadata file 120 is illustrated. Itis noted that for a given directory service 102 and metadata file, themethod illustrated in FIG. 4 is executed by backup application 110 priorto the restore method illustrated in FIG. 2. It is further noted thatcertain steps shown in method 400 may be optional or arranged in adifferent manner in various embodiments. As mentioned previously, themethod 400 provides the advantage of being quick and simple to execute,by using directory service 102 to generate the metadata file 120, at thetime the backup is performed. At the moment the backup is performed, thequery features of directory service 102 are available to backupapplication via interface 107, and the repository in directory service102 is also consistent with the backed up copy of the repository 122.

In step 402, one or more objects are selected, whose metadata is to beincluded in metadata file 120. It is noted that the selection performedin step 402 need not be the same as performed in step 206. In variousembodiments, method 400 may be performed individually or collectivelywith respect to a plurality of data objects. The selection in step 402(along with the other steps in method 400) may be performed “on the fly”(that is during a backup operation), prior to the backup operation, orsubsequent to the backup operation. In step 404, the database is queriedfor metadata for one or more selected data objects, including a POI foreach data object. In certain embodiments of interface 107, a POI may bereturned by a query for a data object. The same POI can be used viainterface 117 to granularly restore that data object in directoryservice 102.

In step 406, the metadata are stored in the metadata file 120. In someembodiments, the metadata file 120 may be stored on a storage medium bya file system. In other embodiments, the metadata file 120 is includedwith the backup copy of the repository 122.

In step 408, the repository of directory service 102 is backed up to thebackup repository 122. As a skilled artisan would recognize, step 408may alternatively be performed different arrangements with respect toorder and parallel execution in various embodiments of method 400. Whileperforming the steps of method 400, care should be taken to prevent anytransactions or usage of directory service 102 that would comprise theconsistency of backup repository 122 with the metadata file 120.

Thus methods 400 and 200 represent backup and restore methods, wherein,among other things, data objects may be granularly (i.e., individually)restored to a database via a directory service. The generation and usageof a POI according to the methods described herein may alternatively beperformed in various other embodiments and contexts, for a variety ofoperational purposes. It is further noted that although data objectshave been described herein in various embodiments, the methods describedherein are equally applicable to various kinds of data identified by therecords of a database, including binary objects of various size and datastored in the fields of the record itself.

For example, an object database may generate a POI for a variety of usesand purposes, depending on the designed architecture of the database. Inone embodiment, a POI is used for securing access to data objects, andincludes encryption by an authenticated certificate. In anotherinstance, POIs are used in conjunction with an access control list torestrict access to data objects. In some embodiments, POIs are used toensure data integrity of the data object, for example by including achecksum of the data object. In yet other embodiments, a POI representsa memory address for accessing data objects cached in faster memory inan object database. In still other embodiments, POIs are generated in anundisclosed manner, for classified access to data objects, wherein thePOI is required for a specific interface to the object database.

Turning now to FIG. 5, a block diagram of one embodiment of a computersystem 500 is illustrated. Computer system 500 includes a processorsubsystem 504 coupled to a memory subsystem 502. Processor subsystem 504and memory subsystem 502 are in turn connected to an I/O subsystem 510,which comprises an I/O interface 512, a hard disk drive 514, a networkinterface 516, and a removable storage 518. Computer system 500 may berepresentative of a laptop, desktop, server, workstation, terminal,personal digital assistant (PDA) or any other type of computer system.

Processor subsystem 504 is representative of any of various types ofprocessors such as an x86 processor, a PowerPC processor or a SPARCprocessor. In some embodiments, processor subsystem 504 includes one ormore individual processor units, which may be found within a singlephysical computer system or distributed across multiple computersystems. Similarly, memory subsystem 502 may include any of varioustypes of memory, including DRAM, SRAM, EDO RAM, Rambus RAM, etc. Thememory within subsystem 502 may be located within a single physicaldevice or may be distributed across multiple devices (e.g., a storagearray).

I/O interface 512 is operational to transfer data between processorsubsystem 504 and/or memory subsystem 502 and one or more internal orexternal components such as hard disk drive 514, network interface 516and removable storage 518, as desired. For example, I/O interface 512may embody a PCI bridge operable to transfer data from processorsubsystem 504 and/or memory subsystem 502 to one or more PCI devices.I/O interface 512 may additionally or alternatively provide an interfaceto devices of other types, such as SCSI devices and/or Fibre channeldevices.

Hard disk drive 514 may be a non-volatile memory such as a magneticmedia. Network interface 516 may be any type of network adapter, such asEthernet, fiber optic, or coaxial adapters. Removable storage 518 isrepresentative of a disk drive, optical media drive, tape drive, orother type of storage media, as desired.

In addition to the depicted hardware components, computer system 500 mayadditionally include various software components. For example, FIG. 5illustrates an operating system 550 stored in memory subsystem 502.Operating system 550 is representative of any of a variety of specificoperating systems, such as, for example, Microsoft Windows, Linux, orSun Solaris. As such, operating system 550 may be operable to providevarious services to the end user and provide a software frameworkoperable to support the execution of various programs such as directoryservice 101 and application program 104. As depicted in one embodimentin FIG. 5, directory service 101 and application program 104 reside oncomputer system 500 and are executed by operating system 550. It isnoted that the depicted software components of FIG. 5 may be paged inand out of memory subsystem 502 in a conventional manner from a storagemedium such as hard drive 514.

In various embodiments (not shown in FIG. 5), portions of applicationprogram 104 reside on a separate computer system from directory service101. For example, backup application 110 may be executed as a service oncomputer system 500, while restore application 130 may be executed on adifferent computer system that accesses backup medium 122 and metadatafile 120.

Referring to FIG. 6, one embodiment of a system 600 is depicted. It isnoted that system 600 may collectively include one or more individualcomputer systems. Accordingly, a processor subsystem associated withsystem 600 may include one or more processors. In this embodiment,domain controller 610 is a server computer that is configured to executea directory service 601 on a network domain. Backup controller 612 is acomputer system that is configured to execute an backup/archiveapplication 604 that accesses a backup medium 622. In the embodimentshown, application program 604 operates in conjunction with anadditional software component, represented by backup agent 620 (shown inthis embodiment as backup agents 620A and 620B), that handles thecommunication between directory service 601 and application program 604.

In this embodiment, one or more software components (e.g., backup agents620) are configured to execute on behalf of application program 604 toperform the backup function. (In FIG. 6, these components are shown as620A and 620B, which may be either identical instances of the samesoftware component, or different components.) Backup agents 620 areconfigured to access directory service 601 on behalf of applicationprogram 604 and return requested information to application program 604.Backup agents 620 may additionally include functionality forencapsulating a network connection to another backup agent orapplication program. Thus, backup agents 620 may be installed locally orremotely and can be configured to relay information over a networkconnection. As shown in FIG. 6, a communication link 630 providesbidirectional communication between backup agents 620A and 620B, whichare configured to communicate with each other by relaying requests andinformation. In other embodiments, application program 604 may reside ona single computer system (e.g., domain controller 610 or computer system500), along with a backup agent (e.g., agent 620).

Note that in some embodiments, a backup application (e.g., 604) and/orassociated software components (e.g., 620) may reside on the samecomputer system with the directory service/database (e.g., domaincontroller 610).

It is noted that in some embodiments, domain controller 610 may be ownedand operated by a different entity than backup controller 612. Invarious embodiments, backup medium 122 (or access thereto) may beprovided by a still different entity. In various embodiments, systems500, 600 are domain controllers and are configured to execute adirectory service for a network domain that includes a plurality ofclient computers. The client computers (not shown in FIG. 5 or 6) may beconfigured to centrally access the directory service executing onsystems 500, 600.

Although the embodiments above have been described in considerabledetail, numerous variations and modifications will become apparent tothose skilled in the art once the above disclosure is fully appreciated.It is intended that the following claims be interpreted to embrace allsuch variations and modifications.

1. A computer system, comprising: a processor subsystem; and a memorysubsystem storing program instructions executable by the processorsubsystem to: copy a plurality of data objects from a database of adirectory service to a backup medium; and for at least a first of saidplurality of copied data objects: query the database to determine afirst private object identifier (POI) associated with the first dataobject, wherein the first POI is providable via a first interface of thedirectory service as part of a request to perform a granular restorationof the first data object, wherein the directory service is configured toauthenticate the request based at least in part on the request includingthe first POI, and wherein the directory service is configured to refuseto authenticate the request based on the request not including the firstPOI; and store the first POI as metadata associated with the first dataobject, wherein the first POI is stored as metadata in a location otherthan the database of the directory service; wherein the computer systemis not configured to generate the first POI from the copy of the firstdata object stored on the backup medium.
 2. The computer system of claim1, wherein said directory service uses a lightweight directory accessprotocol (LDAP).
 3. The computer system of claim 1, wherein saiddatabase is an object database, and wherein without the first POI, thecomputer system is configured to restore the first data object via thefirst interface only by performing a monolithic restoration of theplurality of data objects.
 4. The computer system of claim 1, whereinsaid database is a relational database, and wherein without the firstPOI, the computer system is configured to restore the first data objectvia the first interface only by performing a monolithic restoration ofthe plurality of data objects.
 5. The computer system of claim 1,wherein said backup medium includes a second database, wherein thesecond database stores said plurality of copied data objects.
 6. Thecomputer system of claim 1, wherein the first POI includes an encryptedversion of an object identifier that uniquely identifies the first dataobject.
 7. The computer system of claim 1, wherein generation of thefirst POI uses a proprietary protocol associated with the directoryservice.
 8. The computer system of claim 1, wherein the metadata isstored in a metadata file, and wherein the metadata file includes anindex value and an associated POI for each of one or more of theplurality of copied data objects.
 9. The computer system of claim 8,wherein the metadata file is stored on the backup medium.
 10. Thecomputer system of claim 1, wherein said program instructions arefurther executable by the processor subsystem to: initiate a granularrestoration of said first data object to the directory service; receivesaid first data object from said backup medium; receive previouslystored metadata associated with said first data object, wherein saidmetadata includes said first POI; and use said first POI and saidreceived first data object to granularly restore said first data objectvia said first interface of said directory service.
 11. The computersystem of claim 10, wherein at least a portion of said POI is encrypted.12. The computer system of claim 11, wherein said first interface is acached API, and wherein said first POI is required to access thedirectory service via said first interface.
 13. The computer system ofclaim 10, wherein said computer system is configured to perform saidbackup via a second interface to said directory service.
 14. Thecomputer system of claim 13, wherein said first and second interfaces ofsaid directory service are different interfaces using differentauthentication protocols.
 15. A computer system, comprising: a processorsubsystem; and a memory subsystem storing program instructionsexecutable by the processor subsystem to: initiate a request to performa granular restoration of a first data object from a backup medium to adatabase of a directory service; receive said first data object fromsaid backup medium; receive, from a location external to said database,a first private object identifier associated with said first dataobject, wherein said computer system is not configured to generate saidfirst object identifier from a copy of the first data object stored onsaid backup medium; and use said received first data object and saidreceived first private object identifier to access said database via afirst interface of the directory service to restore said first dataobject, wherein accessing said database to restore said first dataobject is performed according to an authentication protocol thatincludes providing a request including said first private objectidentifier, wherein the directory service is configured to authenticatethe request based at least in part on the request including the firstprivate object identifier, and wherein the directory service isconfigured to refuse to authenticate the request based on the requestnot including said first private object identifier.
 16. The computersystem of claim 15, wherein generation of said first private objectidentifier uses a proprietary protocol associated with the directoryservice, and wherein at least a portion of said first object identifieris encrypted.
 17. The computer system of claim 15, wherein saiddirectory service is accessible using a lightweight directory accessprotocol (LDAP).
 18. A computer-readable memory medium including programinstructions executable by a computer system to: copy a plurality ofdata objects from a database of a directory service to a backup medium;and for at least a first of said plurality of copied data objects, querythe database to determine a first private object identifier (POI)associated with the first data object, wherein the first POI isprovidable via a first interface of the directory service as part of arequest to perform a granular restoration of the first data object,wherein the directory service is configured to authenticate the requestbased at least in part on the request including the first POI, andwherein the directory service is configured to refuse to authenticatethe request based on the request not including the first POI; and storethe first POI as metadata associated with the first data object, whereinthe first POI is stored as metadata in a location other than thedatabase of the directory service; wherein the computer system is notconfigured to generate the first POI from the copy of the first dataobject stored on the backup medium.
 19. The computer-readable memorymedium of claim 18, wherein the directory service uses an LDAP protocol,and wherein the first interface of the directory service is accessiblevia a cached API.
 20. The computer-readable memory medium of claim 18,wherein said program instructions are further executable by the computersystem to: initiate a granular restoration of said first data objectfrom said backup medium to the database; receive said first data objectfrom said backup medium; receive previously stored metadata associatedwith said first data object, wherein said metadata includes said firstPOI; and use said first POI and said received first data object togranularly restore said first data object via said first interface ofsaid directory service.
 21. A computer-readable memory medium includingprogram instructions executable by a computer system to: initiate arequest to perform a granular restoration of a first data object from abackup medium to a database, wherein said database is of a directoryservice; receive said first data object from said backup medium;receive, from a location external to said database, a private objectidentifier associated with said first data object, wherein said computersystem is not configured to generate said private object identifier froma copy of the first data object stored on said first data object storedon said backup medium; and use said received first data object and saidreceived object identifier to access said database via a first interfaceof the directory service to restore said first data object, whereinaccessing said database to restore said first data object is performedaccording to an authentication protocol that includes providing saidprivate object identifier, wherein the directory service is configuredto authenticate the request based at least in part on the requestincluding the private object identifier, and wherein the directoryservice is configured to refuse to authenticate the request based on therequest not including said private object identifier.